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Abstract 
This document defines a network instance module. This module can be 


used to manage the virtual resource partitioning that may be present 
on a network device. Examples of common industry terms for virtual 
resource partitioning are VPN Routing and Forwarding (VRF) instances 
and Virtual Switch Instances (VSIs). 


The YANG data model in this document conforms to the Network 
Management Datastore Architecture (NMDA) defined in RFC 8342. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
https://www.rfc-editor.org/info/rfc8529. 
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1. Introduction 


This document defines the second of two new modules that are defined 
to support the configuration and operation of network devices that 
allow for the partitioning of resources from both, or either, 
management and networking perspectives. Both leverage the YANG 
functionality enabled by YANG Schema Mount [RFC8528]. 


The YANG data model in this document conforms to the Network 
Management Datastore Architecture defined in [RFC8342]. 


The first form of resource partitioning provides a logical 
partitioning of a network device wher ach partition is separately 
managed as essentially an independent network element that is 
"hosted" by the base network device. These hosted network elements 
are referred to as logical network elements, or LNES, and are 
supported by the logical-network-element module defined in [RFC8530]. 
That module is used to identify LNEs and associate resources from the 
network device with each LNE. LNEs themselves are represented in 
YANG as independent network devices; each is accessed independently. 
Examples of vendor terminology for an LNE include logical system or 
logical router and virtual switch, chassis, or fabric. 


The second form, which is defined in this document, provides support 
for what are commonly referred to as VPN Routing and Forwarding (VRF) 
instances as well as Virtual Switch Instances (VSI); see [RFC4026] 
and [RFC4664]. In this form of resource partitioning, multiple 
control-plane and forwarding/bridging instances are provided by and 
managed through a single (physical or logical) network device. This 
form of resource partitioning is referred to as a Network Instance 
(NI) and is supported by the network instance module defined below. 
Configuration and operation of each network instance is always via 
the network device and the network instance module. 


One notable difference between the LNE model and the NI model is that 


the NI model provides a framework for VRF and VSI management. This 
document envisions the separate definition of models specific to VRF 
and VSI -- i.e., L3 and L2 VPN -- technology. An example of such can 


be found in the emerging L3VPN model defined in [YANG-L3VPN] and the 
examples discussed below. 
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1.1. Terminology 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", "SHOULD NOT", 


"RECOMMENDED", 


"OPTIONAL" in this document ar 
BCP 14 [RFC2119] [RFC8174] when, 
capitals, as shown here. 


to b 
and only when, 


"NOT RECOMMENDED", 
interpreted as described 
they appear in 


Readers are expected to be familiar with terms and concepts of 


[RFC7950] and YANG Schema Mount 


[RFC8528]. 


This document uses the graphical representation of data models 


defined in [RFC8340]. 
2. Overview 


In this document, 


" MAY " Y 


and functions defined within the IETF -- e.g., 


routers, 


firewal 


and 
in 
all 


YANG 


we consider network devices that support protocols 


lls, 


and hosts. Such devices may be physical or virtual, e.g., a classic 
router with custom hardware or one residing within a server-based 
virtual machine implementing a virtual network function (VNF). Each 
device may subdivide their resources into logical network elements 
(LNES), each of which provides a managed logical device. Examples of 


vendor terminology for an LNE include logical 


system or logical 


router and virtual switch, 
support VRF and VSI functions, 
instances (NIs). 


or fabric. 
which are referred to below as network 
This breakdown is represented in Figure 1. 


chassis, 


Each LNE may al 
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A model for LNEs is described in [RFC8530], and the model for NIs is 
covered in Section 3 of this document. 


The current interface management model [RFC8343] is impacted by the 
definition of LNEs and NIs. This document and [RFC8530] define 
augmentations to the interface module to support LNEs and NIs. 


The network instance model supports the configuration of VRFs and 
VSIs. Each instance is supported by information that relates to the 
device -- for example, the route target used when advertising VRF 
routes via the mechanisms defined in [RFC4364], and information that 
relates to the internal operation of the NI, such as for routing 
protocols [RFC8349] and OSPF [YANG-OSPF]. This document defines th 
network instance module that provides a basis for the management of 
both types of information. 


NI information that relates to the device, including the assignment 
of interfaces to NIs, is defined as part of this document. The 
defined module also provides a placeholder for the definition of 
NI-technology-specific information both at the device level and for 
NI internal operation. Information related to NI internal operation 
is supported via schema mount [RFC8528] and mounting appropriate 
modules under the mount point. Well-known mount points are defined 
for L3VPN, L2VPN, and L2+L3VPN NI types. 
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3. Network Instances 


The network instance container is used to represent VRFs and VSIs. 
VRFs and VSIs are commonly used to isolate routing and switching 
domains -- for example, to create virtual private networks, each with 
their own active protocols and routing/switching policies. The model 
supports both core/provider and virtual instances. Core/provider 
instance information is accessible at the top level of the server, 
while virtual instance information is accessible under the root 
schema mount points. 


module: ietf-network-instance 
+--rw network-instances 
+--rw network-instance* [name] 


+--rw name string 
+--rw enabled? boolean 
+--rw description? string 


+--rw (ni-type)? 
+--rw (root-type) 


+——: (vrf-root) 
| +--mp vrf-root 
+--: (vsi-root) 
| +--mp vsi-root 
+--: (vv-root) 


+--mp vv-root 
augment /if:interfaces/if:interface: 


+--rw bind-ni-name? —> /network-instances/network-instance/name 
augment /if:interfaces/if:interface/ip:ipv4: 

+--rw bind-ni-name? —> /network-instances/network-instance/name 
augment /if:interfaces/if:interface/ip:ipv6é: 

+--rw bind-ni-name? —> /network-instances/network-instance/name 
notifications: 

+---n bind-ni-name-failed 

+--ro name —> /if:interfaces/interface/nam 


+--ro interface 
+--ro bind-ni-name? 
—> /if:interfaces/interface/ni:bind-ni-name 


+--ro ipv4 
+--ro bind-ni-name? 
-> /if:interfaces/interface/ip:ipv4/ni:bind-ni-name 


+--ro ipvé 
+--ro bind-ni-name? 

-> /if:interfaces/interface/ip:ipv6/ni:bind-ni-name 
+--ro error-info? string 
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A network instance is identified by a "name" string. This string is 
used both as an index within the network instance module and to 
associate resources with a network instance, as shown above in the 
interface augmentation. The ni-type and root-type choice statements 
are used to support different types of L2 and L3 VPN technologies. 
The bind-ni-name-failed notification is used in certain failure 
cases. 


3.1. NI Types and Mount Points 


The network instance module is structured to facilitate the 
definition of information models for specific types of VRFs and VSIs 
using augmentations. For example, the information needed to support 
L2VPN, such as VPLS and EVEN, are likely to be quite different. 
Example models under development that could be restructured to take 
advantage on NIs include models for L3VPNs [YANG-L3VPN] and L2VPNs 
[YANG-L2VPN]. 


Documents defining new YANG data models for the support of specific 
types of network instances should augment the network instance 
module. The basic structure that should be used for such 
augmentations includes a case statement with containers for 
configuration and state data and, when needed, a type-specific mount 
point. Generally, NI types ar xpected to not need to define type- 
specific mount points but rather reuse one of the well-known mount 
points, as defined in the next section. The following is an example 
type-specific augmentation: 


augment "/ni:network-instances/ni:network-instance/ni:ni-type" { 
case 13vpn { 
container 13vpn { 


} 


container 13vpn-state { 
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3.1.1. Well-Known Mount Points 


YANG Schema Mount [RFC8528] identifies mount points by name within a 
module. This definition allows for the definition of mount points 
whose schema can be shared across NI types. As discussed above, 
ni-types largely differ in the configuration information needed in 
the core/top-level instance to support the NI, rather than in the 
information represented within an NI. This allows the use of shared 
mount points across certain NI types. 


The expectation is that there are actually very few different schemas 
that need to be defined to support NIs for an implementation. In 
particular, it is expected that the following three forms of NI 
schema are needed, and each can be defined with a well-known mount 
point that can be reused by future modules defining NI types. 


The three well-known mount points are: 


vrf-root 
vrf-root is intended for use with L3VPN-type NI types. 


vsi-root 
vsi-root is intended for use with L2VPN-type Ni types. 


vv-root 
vv-root is intended for use with NI types that simultaneously 
support L2VPN bridging and L3VPN routing capabilities. 


Future model definitions should use the above mount points whenever 


possible. When a well-known mount point isn't appropriate, a model 
may define a type-specific mount point via augmentation. 
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3. 


3 


1.2. NI Type Example 


The following is an example of an L3VPN VRF using a hypothetical 
augmentation to the network instance schema defined in [YANG-L3VEN]. 
More detailed examples can be found in Appendix A. 


module: ietf-network-instance 
+--rw network-instances 
+--rw network-instance* [name] 


+--rw name string 
+--rw enabled? boolean 
+--rw description? string 
+--rw (ni-type)? 

| +——: (13vpn) 


| +--rw 13vpn:13vpn 
|... // config data 
+--ro l3vpn:l3vpn-state 
| | it // state data 
+--rw (root-type) 
+--: (vrf-root) 
+--mp vrf-root 
+--rw rt:routing/ 
+--rw router-id? yang: dotted-quad 
+--rw control-plane-protocols 
+--rw control-plane-protocol* [type name] 
+--rw ospf:ospf 
+--rw area“ [area-id] 
+--rw interfaces 
+--rw interface“ [name] 
+--rw name if:interface-ref 
+--rw cost? uint16 


+--ro if:interfaces@ 


This shows YANG Routing Management [RFC8349] and YANG OSPF 
[YANG-OSPF] as mounted modules. The mounted modules can reference 
interface information via a parent-reference to the containers 
defined in [RFC8343]. 


-2. NIs and Interfaces 


Interfaces are a crucial part of any network device’s configuration 
and operational state. They generally include a combination of raw 
physical interfaces, link-layer interfaces, addressing configuration, 
and logical interfaces that may not be tied to any physical 
interface. Several system services and Layer 2 and Layer 3 protocols 
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may also associate configuration or operational state data with 
different types of interfaces (Lhese relationships are not shown for 
simplicity). The interface management model is defined by [RFC8343]. 


As shown below, the network instance module augments the existing 
interface management model by adding a name that is used on interface 
or sub-interface types to identify an associated network instance. 
Similarly, this name is also added for IPv4 and IPv6 types, as 
defined in [RFC8344]. 


The following is an example of envisioned usage. The interfaces 
container includes a number of commonly used components as examples: 


module: ietf-interfaces 
+--rw interfaces 


+--rw interface* [name] 
+--rw name string 
+--rw ip:ipv4! 
+--rw ip:enabled? boolean 
+--rw ip: forwarding? boolean 
+--rw ip:mtu? uint16 
+--rw ip:address* [ip] 
+--rw ip:ip inet: ipv4-address-no-zone 
+--rw (ip:subnet) 
+--:(ip:prefix-length) 
| +--rw ip:prefix-length?  uint8 
+--:(ip:netmask) 
+--rw ip:netmask? yang: dotted-quad 
+--rw ip:neighbor* [ip] 
+--rw ip:ip inet: ipv4-address-no-zone 
+--rw ip:link-layer-address yang:phys-address 
+--rw ni:bind-network-instance-name? string 
+--rw ni:bind-network-instance-name? string 


The "ietf-interfaces" module [RFC8343] is structured to include all 
interfaces in a flat list, without regard to virtual instances (e.g., 
VRFs) supported on the device. The bind-network-instance-name leaf 
provides the association between an interface and its associated NI 
(e.g., VRF or VSI). Note that as currently defined, to assign an 
interface to both an LNE and an NI, the interface would first be 
assigned to the LNE using the mechanisms defined in [RFC8530] and 
then, within that LNE’s interface module, the LNE’s representation of 
that interface would be assigned to an NI. 
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3.3. Network Instance Management 


Modules that may be used to represent network instance information 
will be available under the "root" mount point specific to the 
ni-type. The "shared-schema" method defined in the "ietf-yang- 
schema-mount" module [RFC8528] MUST be used to identify accessible 
modules. A future version of this document could relax this 
requirement. Mounted modules SHOULD be defined with access, via the 
appropriate schema mount parent-references [RFC8528], to device 
resources such as interfaces. An implementation MAY choose to 
restrict parent-referenced information to information related to a 
specific instance. For example, it might only allow references to 
interfaces that have a "bind-network-instance-name" that is identical 
to the instance’s "name". 


All modules that represent control-plane and data-plane information 
may be present at the "root" mount point and accessible via paths 
modified per [RFC8528]. The list of available modules is expected to 
be implementation dependent, as is the method used by an 
implementation to support NIs. 


For example, the following could be used to define the data 
organization of the example NI shown in Section 3.1.2: 


"ietf-yang-schema-mount:schema-mounts": { 
"mount-point": [ 


{ 


"module": "ietf-network-instance", 
"label": "vrf-root", 
"shared-schema": { 
"parent-reference": | 
"/“Inamespace-uri() = ’urn:ietf:...:ietf-interfaces’]" 


] 


} 


Module data identified according to the ietf-yang-schema-mount module 
will be instantiated under the mount point identified under 
"mount-point". These modules will be able to reference information 
for nodes belonging to top-level modules that are identified under 
"parent-reference". Parent-referenced information is available to 
clients via their top-level paths only and not under the associated 
mount point. 
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Low a client to understand the previously mentioned instance 


represent such restrictions in the "parent-reference" leaf-list. 


examp1 


Le: 


"namespace": [ 


{ 


}, 
{ 


} 
1, 


N ZR E SAME, 
"uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces" 


"prefix": "ni", 
"uri": "urn:ietf:params:xml:ns:yang:ietf-network-instance" 


"mount-point": [ 


{ 


"module": "ietf-network-instance", 
"label": "vrf-root", 
"shared-schema": { 
"parent-reference": | 
"/if:interfaces/if: interface 


an implementation MAY 


For 


Ini:bind-network-instance-name = current ()/../ni:name|", 


"/if:interfaces/if:interface/ip:ipv4 


[ni:bind-network-instance-name = current()/../ni:name]", 


"/if:interfaces/if:interface/ip:ipv6 


[ni:bind-network-instance-name = current()/../ni:name]" 
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The same such "parent-reference" restrictions for non-NMDA 
implementations can be represented based on [RFC8343] and [RFC8344] 
as: 
"namespace": [ 
{ 
"prefix Ts Mit", 
"uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces" 
}, 
{ 
"prefix": "ni", 
"uri": "urn:ietf:params:xml:ns:yang:ietf-network-instance" 


} 
l, 
"mount-point": [ 


{ 


"module": "ietf-network-instance", 
"label": "vrf-root", 
"shared-schema": { 


K"parent-reference": [ 
"/if:interfaces/if: interface 


ni:bind-network-instance-name = current ()/../ni:namel", 
"/if:interfaces-state/if:interface 
if:name = /if:interfaces/if:interface 
[ni:bind-ni-name = current ()/../ni:name]/if:namel]", 
"/if:interfaces/if:interface/ip:ipv4 
ni:bind-network-instance-name = current()/../ni:name]", 
"/if:interfaces-state/if:interface/ip:ipv4 
if:name = /if:interfaces/if:interface/ip:ipv4 
[ni:bind-ni-name = current()/../ni:name]/if:name]", 
"/if:interfaces/if:interface/ip:ipv6 
ni:bind-network-instance-name = current()/../ni:name]", 
"/if:interfaces-state/if:interface/ip:ipv6é 
if:name = /if:interfaces/if:interface/ip:ipv6é 
[ni:bind-ni-name = current()/../ni:name]/if:name]" 
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3.4. Network Instance Instantiation 


Network instances may be controlled by clients using existing list 
operations. When a list entry is created, a new instance is 
instantiated. The models mounted under an NI root are expected to be 
dependent on the server implementation. When a list entry is 
deleted, an existing network instance is destroyed. For more 
information, see Section 7.8.6 of [RFC7950]. 


Once instantiated, host network device resources can be associated 
with the new NI. As previously mentioned, this document augments 
ietf-interfaces with the bind-ni-name leaf to support such 
associations for interfaces. When a bind-ni-name is set to a valid 
NI name, an implementation MUST take whatever steps are internally 
necessary to assign the interface to the NI or provide an error 
message (defined below) with an indication of why the assignment 
failed. It is possible for the assignment to fail while processing 
the set operation or after asynchronous processing. Error 
notification in the latter case is supported via a notification. 


4. Security Considerations 


The YANG modules specified in this document define a schema for data 
that is designed to be accessed via network management protocols such 
as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 
is the secure transport layer, and the mandatory-to-implement secure 
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 
is HTTPS, and the mandatory-to-implement secure transport is TLS 
[RFC8446]. 


The Network Configuration Access Control Model (NACM) [RFC8341] 
provides the means to restrict access for particular NETCONF or 
RESTCONF users to a preconfigured subset of all available NETCONF or 
RESTCONF protocol operations and content. 


There are two different sets of security considerations to consider 
in the context of this document. One set is security related to 
information contained within mounted modules. The security 
considerations for mounted modules are not substantively changed 
based on the information being accessible within the context of an 
NI. For example, when considering the modules defined in [RFC8349], 
the security considerations identified in that document are equally 
applicable, whether those modules are accessed at a server’s root or 
under an NI instance’s root node. 
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The second area for consideration is information contained in the NT 
module itself. NI information represents network configuration and 
route distribution policy information. As such, the security of this 
information is important, but it is fundamentally no different than 
any other interface or routing configuration information that has 
already been covered in [RFC8343] and [RFC8349]. 


The vulnerable "config true" parameters and subtrees are the 
following: 


/network-instances/network-instance: This list specifies the network 
instances and the related control plane protocols configured on a 
device. 


/if:interfaces/if:interface/*/bind-network-instance-name: This leaf 
indicates the NI instance to which an interface is assigned. 


Unauthorized access to any of these lists can adversely affect the 

routing subsystem of both the local device and the network. This may 

lead to network malfunctions, delivery of packets to inappropriate 

destinations, and other problems. 

5. IANA Considerations 

This document registers a URI in the "IETF XML Registry" [RFC3688]. 
URI: urn:ietf:params:xml:ns:yang:ietf-network-instance 
Registrant Contact: The IESG. 


XML: N/A, the requested URI is an XML namespace. 


This document registers a YANG module in the "YANG Module Names" 
registry [RFC6020]. 


name: ietf-network-instance 

namespace: urn:ietf:params:xml:ns:yang:ietf-network-instance 
prefix: ni 

reference: RFC 8529 
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6. Network Instance Model 


The structure of the model defined in this document is described by 
the YANG module below. 


<CODE BEGINS> file "ietf-network-instance@2019-01-21.yang" 
module ietf-network-instance { 
yang-version 1.1; 
namespace "urn:ietf:params:xml:ns:yang:ietf-network-instance"; 
prefix ni; 


// import some basic types 


import ietf-interfaces { 
prefix if; 
reference 
"RFC 8343: A YANG Data Model for Interface Management"; 
} 
import ietf-ip ( 
prefix ip; 
reference 
"RFC 8344: A YANG Data Model for IP Management"; 
} 
import ietf-yang-schema-mount { 
prefix yangmnt; 
reference 
"RFC 8528: YANG Schema Mount"; 
} 


organization 
"IETF Routing Area (rtgwg) Working Group"; 
contact 
"WG Web: <https://datatracker.ietf.org/wg/rtgwg> 
WG List: <mailto:rtgwg@ietf.org> 
Author: Lou Berger 
<mailto:lberger@labn.net> 
Author: Christian Hopps 
<mailto:chopps@chopps.org> 
Author: Acee Lindem 
<mailto:acee@cisco.com> 
Author: Dean Bogdanovic 
<mailto:ivandean@gmail.com>"; 


description 
"This module is used to support multiple network instances 
within a single physical or virtual device. Network 
instances are commonly known as VRFs (VPN Routing and 
Forwarding) and VSIs (Virtual Switching Instances). 
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The key words 'MUST', ‘MUST NOT’, 'REQUIRED', 'SHALL', 
‘SHALL NOT’, ’SHOULD’, ' SHOULD NOT’, ’RECOMMENDED’, 

"NOT RECOMMENDED’, 'MAY', and ’OPTIONAL’ in this document 
are to be interpreted as described in BCP 14 (RFC 2119) 

(RFC 8174) when, and only when, they appear in all capitals, 
as shown here. 


Copyright (c) 2019 IETF Trust and the persons identified as 
authors of the code. All rights reserved. 


Redistribution and use in source and binary forms, with or 
without modification, is permitted pursuant to, and subject 
to the license terms contained in, the Simplified BSD 
License set forth in Section 4.c of the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(https://trustee.ietf.org/license-info). 


This version of this YANG module is part of RFC 8529; see 
the RFC itself for full legal notices."; 


revision 2019-01-21 í 
description 
"Initial revision."; 
reference 
RFC 85290 
} 


// top-level device definition statements 


container network-instances { 
description 
"Network instances, each of which consists of 
VRFS and/or VSIs."; 
reference 
"RFC 8349: A YANG Data Model for Routing Management"; 
list network-instance { 
key "name"; 
description 
"List of network instances."; 
leaf name { 
type string; 
mandatory true; 
description 
"device-scoped identifier for the network 
instance."; 
} 
leaf enabled { 
type boolean; 
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default "true"; 
description 
"Flag indicating whether or not the network 
instance is enabled."; 
} 
leaf description { 
type string; 
description 
"Description of the network instance 
and its intended purpose."; 
} 


choice ni-type { 


description 
"This node serves as an anchor point for different types 
of network instances. Each 'case' is expected to 


differ in terms of the information needed in the 
parent/core to support the NI and may differ in their 
mounted-schema definition. When the mounted schema is 
not expected to be the same for a specific type of NI, 
a mount point should be defined."; 


} 
choice root-type (| 
mandatory true; 
description 
"Well-known mount points." 
container vrf-root { 
description 
"Container for mount point."; 
yangmnt :mount-point "vrf-root" í 
description 
"Root for L3VPN-type models. This will typically 
not be an inline-type mount point."; 


} 
} 


container vsi-root { 
description 
"Container for mount point."; 
yangmnt:mount-point "vsi-root" í 
description 
"Root for L2VPN-type models. This will typically 
not be an inline-type mount point."; 


} 
container vv-root { 
description 
"Container for mount point."; 
yangmnt:mount-point "vv-root" { 
description 
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"Root models that support both L2VPN-type bridging 
and L3VPN-type routing. This will typically 
not be an inline-type mount point."; 


} 
// augment statements 


augment "/if:interfaces/if:interface" { 
description 
"Add a node for the identification of the network 
instance associated with the information configured 
on a interface. 


Note that a standard error will be returned if the 
identified leafref isn’t present. If an interface cannot 
be assigned for any other reason, the operation SHALL fail 
with an error-tag of ’operation-failed’ and an 
error-app-tag of 'ni-assignment-failed'. A meaningful 
error-info that indicates the source of the assignment 
failure SHOULD also be provided."; 
leaf bind-ni-name { 
type leafref { 
path "/network-instances/network-instance/name"j 
} 
description 
"Network instance to which an interface is bound."; 


} 
} 
augment "/if:interfaces/if:interface/ip:ipv4" { 
description 
"Add a node for the identification of the network 
instance associated with the information configured 
on an IPv4 interface. 


Note that a standard error will be returned if the 
identified leafref isn’t present. If an interface cannot 
be assigned for any other reason, the operation SHALL fail 
with an error-tag of 'operation-failed' and an 
error-app-tag of 'ni-assignment-failed'. A meaningful 
error-info that indicates the source of the assignment 
failure SHOULD also be provided."; 
leaf bind-ni-name { 

type leafref { 
path "/network-instances/network-instance/name"j 
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} 
description 
"Network instance to which IPv4 interface is bound."; 
} 
} 
augment "/if:interfaces/if:interface/ip:ipv6" { 
description 
"Add a node for the identification of the network 
instance associated with the information configured 
on an IPv6 interface. 


Note that a standard error will be returned if the 
identified leafref isn’t present. If an interface cannot 
be assigned for any other reason, the operation SHALL fail 
with an error-tag of 'operation-failed’ and an 
error-app-tag of 'ni-assignment-failed'. A meaningful 
error-info that indicates the source of the assignment 
failure SHOULD also be provided."; 
leaf bind-ni-name { 

type leafref { 
path "/network-instances/network-instance/name"j 

} 

description 

"Network instance to which IPv6 interface is bound."; 


} 
// notification statements 


notification bind-ni-name-failed { 


description 
"Indicates an error in the association of an interface to an 
NI. Only generated after success is initially returned when 


bind-ni-name is set. 


Note: Some errors may need to be reported for multiple 
associations, e.g., a single error may need to be reported 
for an IPv4 and an IPv6 bind-ni-name. 


At least one container with a bind-ni-name leaf MUST be 
included in this notification."; 
leaf name { 
type leafref { 
path "/if:interfaces/if:interface/if:name"; 
} 
mandatory true; 
description 
"Contains the interface name associated with the 
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failure."; 
} 
container interface { 
description 
"Generic interface type."; 
leaf bind-ni-name { 
type leafref { 
path "/if:interfaces/if:interface" 
+ "/ni:bind-ni-name"; 
} 
description 
"Contains the bind-ni-name associated with the 
failure."; 
} 
} 
container ipv4 { 
description 
"IPv4 interface type."; 
leaf bind-ni-name { 
type leafref { 
path "/if:interfaces/if:interface/ip:ipv4/ni:bind-ni-name"; 


} 
description 
"Contains the bind-ni-name associated with the 
failure."; 
} 
} 
container ipve { 
description 
"IPv6 interface type."; 
leaf bind-ni-name { 
type leafref { 
path "/if:interfaces/if:interface/ip:ipv6" 
+ "/ni:bind-ni-name"; 
} 
description 
"Contains the bind-ni-name associated with the 
failure."; 
} 
} 
leaf error-info { 
type string; 
description 
"Optionally, indicates the source of the assignment 
failure."; 
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Appendix A. Example NI Usage 


The following subsections provid xample uses of NIs. 


A.1. Configuration Data 


The following shows an example where two customer-specific network 
instances are configured: 


{ 
"jetf-network-instance:network-instances": { 
"network-instance": | 
{ 
"name": "vrf-red", 
"yrf-root": { 

"ietf-routing:routing": { 
Mrouter-1d": "1925052 5.18, 
"control-plane-protocols": { 

"control-plane-protocol": [ 


{ 


"type": "ietf-routing:ospf", 
"name " : " gu z 
"ietf-ospf:ospf": { 
Wak "ipv4", 
"areas": í 
"area": | 


{ 
"area-id": "203.0.113.1", 


"interfaces": { 
"interface": [ 
{ 
"name": "ethl", 
"cost": 10 


"name": "vrf-blue", 
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aye = OO SE, À 
"ietf-routing:routing": { 
Mroutér-id'"; “192.0252; 
"control-plane-protocols": { 
"control-plane-protocol": [ 


{ 


"type": "ietf-routing:ospf", 
"name": TEN 
"ietf-ospf:ospf": { 
Weak Nes "ipv4", 
"areas": { 
"area": | 
{ 
"area-id": "203.0.113.1", 
"interfaces": { 
"interface": [ 
{ 
"name": "eth2", 
"cost"; J.O 
} 
] 
} 
} 
] 
} 
} 
} 
] 
} 
} 
} 
} 
] 
}, 
"jetf-interfaces:interfaces": { 
"interface": [ 
{ 
"name": "eth0", 
"type": "iana-if-type:ethernetCsmacd", 
"ietf-ip:ipv4": { 
"address": [ 
{ 
Tipe WOO D 2s LOM, 


"prefix-length": 24 


}, 
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Mietf-ip:ipvé": { 
"address": [ 
{ 
"ip": "2001:db8:0:2::10", 
"prefix-length": 64 


"name": "ethl", 
"type": "iana-if-type:ethernetCsmacd", 
"ietf-ip:ipv4": 1 
"address": [ 
{ 
tes “192.0.2. 101", 
"prefix-length": 24 


] 
}, 
"ietf-ip:ipv6": { 
"address": [ 
{ 
Tip": "2001:db850:2::11", 
"prefix-length": 64 


] 
}, 


"ietf-network-instance:bind-network-instance-name": "vrf-red" 


"name": "eth2", 
"type": "iana-if-type:ethernetCsmacd", 
"ietf-ip:ipv4": { 
"address": [ 
{ 
tipte MOD 023 rit 
"prefix-length": 24 


] 
}, 
“ietf-ip:ipv6": ( 
"address": [ 
{ 
"ip": "2001:db8:0:2::11", 
"prefix-length": 64 
} 
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}, 
“"ietf-network-instance:bind-network-instance-name": 
"yrf-blue" 


] 
}, 


"ietf-system:system": { 
"authentication": { 
"user": [ 
{ 
"name": "john", 
"password": "SOSpassword" 


A.2. State Data - Non-NMDA Version 


The following shows state data for the configuration example above 
based on [RFC8343], [RFC8344], and [RFC8349]. 


"jetf-network-instance:network-instances": { 
"network-instance": | 
{ 
"name": "vrf-red", 
"yrf-root": { 
"ietf-yang-library:modules-state": { 
"module-set-id": "123e4567-e89b-12d3-a456-426655440000", 
"module": [ 


{ 


"name": "ietf-yang-library", 

"revision": "2019-01-04", 

"namespace": 
"urn:ietf:params:xml:ns:yang:ietf-yang-library", 

"conformance-type": "implement" 


"name": "ietf-ospf", 

"revision": "2019-01-24", 

"namespace": "urn:ietf:params:xml:ns:yang:ietf-ospf", 
"conformance-type": "implement" 


"name": "ietf-routing", 
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K"revision": "2018-03-13", 
"namespace": "urn:ietf:params:xml:ns:yang:ietf-routing", 
"conformance-type": "implement" 
) 
] 
}, 
"ietf-routing:routing-state": { 
"router-id": "192.0.2.1", 
"control-plane-protocols": { 
"control-plane-protocol": [ 


{ 


"type": "ietf-routing:ospf", 
"name " : " r e 
"ietf-ospf:ospf": { 
Maps "ipv4", 
"areas": í 
"area": [ 


{ 
"area-id": "203.0.113.1", 


"interfaces": { 
"interface": [ 
{ 
"name": "ethl", 
"Cost": 10 
} 
] 
} 
} 
] 
} 
} 
} 
] 
} 
} 
} 
}, 
{ 
"name": "vrf-blue", 
Bee "EX À 
"ietf-yang-library:modules-state": { 
"module-set-id": "123e4567-e89b-12d3-a456-426655440000", 
"module": [ 
{ 
"name": "ietf-yang-library", 
"revision": "2019-01-04", 
"namespace": 


"urn:ietf:params:xml:ns:yang:ietf-yang-library", 
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"conformance-type": "implement" 


"name": "ietf-ospf", 

"revision": "2019-01-24", 

"namespace": "urn:ietf:params:xml:ns:yang:ietf-ospf", 
"conformance-type": "implement" 


"name": "ietf-routing", 

K"revision": "2018-03-13", 

"namespace": "urn:ietf:params:xml:ns:yang:ietf-routing", 
"conformance-type": "implement" 


] 
}, 
"ietf-routing:routing-state": { 
Mrouter-1d": "1920221, 
"control-plane-protocols": { 
"control-plane-protocol": [ 


{ 


"type": "ietf-routing:ospf", 
"name " : " h s 
"ietf-ospf:ospf": { 
MARAS "ipv4", 
"areas": { 
"area": [ 


{ 
"area-id": "203.0.113.1", 


"interfaces": { 
"interface": [ 
{ 
"name": "eth2", 
"cost": 10 
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}, 


"ietf-interfaces:interfaces-state": { 
"interface": [ 
{ 
"name": "eth0", 
"type": "iana-if-type:ethernetCsmacd", 
"oper-status": "up", 
"phys-address": "00:01:02:A1:B1:C0", 
"statistics": ( 
"discontinuity-time": "2017-06-26T12:34:56-05:00" 
}, 
"ietf-ip:ipv4": { 
"address": [ 
{ 
Was MOD E S 
"prefix-length": 24 


] 
}, 
Mietf-ip:ipvé": ( 
"address": [ 
{ 
"ip": "2001:db8:0:2::10", 
"prefix-length": 64 


"name": "eth1", 
"type": "iana-if-type:ethernetCsmacd", 
"oper-status": "up", 
"phys-address": "00:01:02:A1:B1:C1", 
"statistics": ( 
"discontinuity-time": "2017-06-26T12:34:56-05:00" 


}, 
"ietf-ip:ipv4": ( 
"address": [ 
{ 
wip" e "192.022.0110", 
"prefix-length": 24 


] 
}, 
"ietf-ip:ipv6": { 
"address": [ 


{ 
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"ip": "2001:db8:0:2::11", 
"prefix-length": 64 


"name": "eth2", 
"type": "iana-if-type:ethernetCsmacd", 
"oper-status": "up", 
"phys-address": "00:01:02:A1:B1:C2", 
"Statistics": { 
"discontinuity-time": "2017-06-26T12:34:56-05:00" 


}, 
"ietf-ip:ipv4": ( 
"address": [ 
{ 
Tip"? “VOD. O02 LS, 
"prefix-length": 24 


] 
}, 
"ietf-ip:ipv6": ( 
"address": [ 
{ 
"ip": "2001:db8:0:2::11", 
"prefix-length": 64 


"ietf-system:system-state": { 
"platform": { 
"os-name": "NetworkOS" 
} 
}, 


"ietf-yang-library:modules-state": { 
"module-set-id": "123e4567-e89b-12d3-a456-426655440000", 
"module": [ 
{ 
"name": "iana-if-type", 
"revision": "2018-07-03", 


March 2019 


"namespace": "urn:ietf:params:xml:ns:yang:iana-if-type", 


"conformance-type": "import" 
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}, 
{ 


"name": "ietf-inet-types", 
"revision": "2013-07-15", 
"namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types", 
"conformance-type": "import" 
}, 
{ 
"name": "ietf-interfaces", 
"revision": "2018-02-20", 
"feature": [ 


"arbitrary-names", 
"pre-provisioning" 


l; 


"namespace": "urn:ietf:params:xml:ns:yang:ietf-interfaces", 
"conformance-type": "implement" 
}, 
{ 
"name": "ietf-ip", 
"revision": "2018-01-09", 
"namespace": "urn:ietf:params:xml:ns:yang:ietf-ip", 
"conformance-type": "implement" 
}, 
{ 
"name": "ietf-network-instance", 
"revision": "2018-02-03", 
"feature": [ 


"bind-network-instance-name" 
l, 
"namespace": 
"urn:ietf:params:xml:ns:yang:ietf-network-instance", 
"conformance-type": "implement" 


"name": "ietf-ospf", 

"revision": "2019-01-24", 

"namespace": "urn:ietf:params:xml:ns:yang:ietf-ospf", 
"conformance-type": "implement" 


"name": "ietf-routing", 

"revision": "2018-03-13", 

"namespace": "urn:ietf:params:xml:ns:yang:ietf-routing", 
"conformance-type": "implement" 


"name": "ietf-system", 
"revision": "2014-08-06", 
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"namespace": "urn:ietf:params:xml:ns:yang:ietf-system", 
"conformance-type": "implement" 

}, 

{ 
"name": "ietf-yang-library", 
"revision": "2019-01-04", 
"namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-library", 
"conformance-type": "implement" 

}, 

{ 
"name": "ietf-yang-schema-mount", 
"revision": "2019-01-14", 
"namespace": 

"urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount", 

"conformance-type": "implement" 

}, 

{ 
"name": "ietf-yang-types", 
"revision": "2013-07-15", 
"namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types", 
"conformance-type": "import" 

} 

] 
}, 
"ietf-yang-schema-mount:schema-mounts": { 


"mount-point": [ 


{ 


"module": "ietf-network-instance", 
"label": "vrf-root", 
"shared-schema": { 
"parent-reference": | 
"/“Inamespace-uri() = ’urn:ietf:...:ietf-interfaces’]" 


] 
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A.3. State Data - NMDA Version 


The following shows state data for the configuration example abov 
based on [RFC8343], [RFC8344], and [RFC8349]. 


"ietf-network-instance:network-instances": { 
"network-instance": [ 
{ 
"name": "vrf-red", 
"vrf-root": { 
"ietf-yang-library:yang-library": ( 
"content-id": "4le2ab5dc325f6d86f743e8da3de323f1a61a801", 
"module-set": [ 


{ 


"name": "ni-modules", 
"module": [ 
{ 
"name": "ietf-yang-library", 
"revision": "2019-01-04", 
"namespace": 


"urn:ietf:params:xml:ns:yang:ietf-yang-library" 


"name": "ietf-ospf", 
"revision": "2019-01-24", 
"namespace": 


"urn:ietf:params:xml:ns:yang:ietf-ospf" 


"name": "ietf-routing", 
"revision": "2018-03-13", 
"namespace": 


"urn:ietf:params:xml:ns:yang:ietf-routing" 
} 
l, 
"import-only-module": [ 


{ 


"name": "ietf-inet-types", 
"revision": "2013-07-15", 
"namespace": 


"urn:ietf:params:xml:ns:yang:ietf-inet-types" 


"name": "ietf-yang-types", 
"revision": "2013-07-15", 
"namespace": 


"urn:ietf:params:xml:ns:yang:ietf-yang-types" 
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}, 
{ 


"name": "ietf-datastores", 
"revision": "2018-02-14", 
"namespace": 


"Turn: ietf :params:xml:ns: yang: ietf-datastores" 


) 
1, 


"schema": [ 
{ 
"name": "ni-schema", 
"module-set": [ "ni-modules" ] 
} 
l, 
"datastore": L 
{ 
"name": "ietf-datastores:running", 
"schema": "ni-schema" 
}, 
{ 
"name": "ietf-datastores:operational", 
"schema": "ni-schema" 
} 
] 
}, 
"ietf-routing:routing": ( 
"router-id": "192.0.2.1", 
"control-plane-protocols": { 


"control-plane-protocol": [ 


{ 


"type": "ietf-routing:ospf", 
"name " : " 1T z 
"ietf-ospf:ospf": { 
Week s "ipv4", 
"areas": í 
"area": [ 


{ 
"area-id": "203.0.113.1", 


"interfaces": { 
"interface": [ 
{ 
"name": "eth1l", 
Teost JO 
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"name": 
"vrf-root": 
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"yrf-blue", 


{ 


"ietf-yang-library:yang-library": { 


"checksum": 


"Ale2ab5dc325f6d86f743e8da3de323f1a61a801", 


"module-set": [ 


{ 


"name": "ni-modules", 
"module": [ 
{ 
"name": "ietf-yang-library", 
"revision": "2019-01-04", 
"namespace": 


} 
l; 


"urn:ietf:params:xml:ns:yang:ietf-yang-library", 
"conformance-type": "implement" 


"name": "ietf-ospf", 
"revision": "2019-01-24", 
"namespace": 


"urn:ietf:params:xml:ns:yang:ietf-ospf", 
"conformance-type": "implement" 


"name": "ietf-routing", 
"revision": "2018-03-13", 
"namespace": 


"urn:ietf:params:xml:ns:yang:ietf-routing", 
"conformance-type": "implement" 


"import-only-module": [ 


{ 


}, 
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"name": "ietf-inet-types", 
"revision": "2013-07-15", 
"namespace": 


"urn:ietf:params:xml:ns:yang:ietf-inet-types" 
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} 
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"name": "ietf-yang-types", 
"revision": "2013-07-15", 
"namespace": 


March 2019 


"urn:ietf:params:xml:ns:yang:ietf-yang-types" 


"name": "ietf-datastores", 
"revision": "2018-02-14", 
"namespace": 


"urn:ietf:params:xml:ns:yang:ietf—-datastores" 


"schema": [ 
{ 
"name": "ni-schema", 
"module-set": (| "ni-modules" | 
l, 
"datastore": [ 
"name": "ietf-datastores:running", 
"schema": "ni-schema" 
U 
"name": "ietf-datastores:operational", 
"schema": "ni-schema" 
] 
}, 
"ietf-routing:routing": { 
“routér-1d"? 1192102021”, 
"control-plane-protocols": { 


et al. 


"control-plane-protocol": [ 


{ 


"type": "ietf-routing:ospf", 
"name " : " 1" F 
"ietf-ospf:ospf": { 
Wan: "ipv4", 
"areas": í 
"area": | 


{ 
Warea-ia™s "203001131 "7 
"interfaces": ( 
"interface": [ 


{ 
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"name": "eth2", 
"cost": 10 


"ietf-interfaces:interfaces": { 
"interface": [ 
{ 
"name": "eth0", 
"type": "iana-if-type:ethernetCsmacd", 
"oper-status": "up", 
"phys-address": "00:01:02:A1:B1:C0", 
"Statistics": { 
"discontinuity-time": "2017-06-26T12:34:56-05:00" 


}, 
"ietf-ip:ipv4": { 
"address": [ 
{ 
nipte "192-0 OR 
"prefix-length": 24 
} 
] 
}, 
Mietf-ip:ipvé": ( 
"address": [ 
{ 
"ip": "2001:db8:0:2::10", 
"prefix-length": 64 
} 


"name": "eth1", 
"type": "iana-if-type:ethernetCsmacd", 


Berger, et al. Standards Track [Page 39] 


RFC 8529 YANG NIs March 2019 


"oper-status": "up", 
"phys-address": "00:01:02:A1:B1:C1", 
"statistics": í 
"discontinuity-time": "2017-06-26T12:34:56-05:00" 


}, 
“ietf-ip:ipv4": { 
"address": [ 
{ 
tipte 41:92: 0.2. 115; 
"prefix-length": 24 
} 
] 
}, 
"ietf-ip:ipve": ( 
"address": [ 
{ 
"ip": "2001:db8:0:2::11", 
"prefix-length": 64 
} 


"name": "eth2", 
"type": "iana-if-type:ethernetCsmacd", 
"oper-status": "up", 
"phys-address": "00:01:02:A1:B1:C2", 
"Statistics": { 
"discontinuity-time": "2017-06-26T12:34:56-05:00" 


}, 
"ietf-ip:ipv4": { 
"address": [ 
{ 
Tps M192::0:2 11"; 
"prefix-length": 24 
} 
] 
}, 
"ietf-ip:ipv6": { 
"address": [ 
{ 
Tipt "200ddbs:0 323511; 
"prefix-length": 64 
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}, 


"ietf-system:system-state": { 
"platform": { 
"os-name": "NetworkOS" 


} 
}, 


"ietf-yang-library:yang-library": ( 
"content-id": "75a43df9bd56b92aacc156a2958fbe12312fb285", 
"module-set": [ 
{ 
"name": "host-modules", 
"module": [ 
{ 
"name": "ietf-interfaces", 
"revision": "2018-02-20", 
"feature": [ 
"arbitrary-names", 
"pre-provisioning" 
1, 
"namespace": 
"urn:ietf:params:xml:ns:yang:ietf-—interfaces" 


"name": "ietf-ip", 

"revision": "2018-01-09", 

"namespace": "urn:ietf:params:xml:ns:yang:ietf-ip" 
}, 
{ 

"name": "ietf-network-instance", 

"revision": "2018-02-03", 

"feature": [ 


"bind-network-instance-name" 

1, 

"namespace": 
"urn:ietf:params:xml:ns:yang:ietf-network-instance" 


"name": "ietf-ospf", 
"revision": "2019-01-24", 
"namespace": 


"urn:ietf:params:xml:ns:yang:ietf-ospf" 


"name": "ietf-routing", 
"revision": "2018-03-13", 
"namespace": 


Berger, et al. Standards Track [Page 41] 


RFC 8529 YANG NIs March 2019 


"urn:ietf:params:xml:ns:yang:ietf-routing" 


"name": "ietf-system", 

"revision": "2014-08-06", 

"namespace": "urn:ietf:params:xml:ns:yang:ietf-system" 
}, 
{ 

"name": "ietf-yang-library", 

"revision": "2019-01-04", 

"namespace": 


"urn:ietf:params:xml:ns:yang:ietf-yang-library" 


"name": "ietf-yang-schema-mount", 
"revision": "2019-01-14", 
"namespace": 


"urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount" 
} 
l, 
"import-only-module": [ 


{ 
"name": "iana-if-type", 
"revision": "2018-07-03", 
"namespace": "urn:ietf:params:xml:ns:yang:iana-if-type" 
}, 
{ 
"name": "ietf-inet-types", 
"revision": "2013-07-15", 
"namespace": 
"urn:ietf:params:xml:ns:yang:ietf-inet-types" 
}, 
{ 
"name": "ietf-yang-types", 
"revision": "2013-07-15", 
"namespace": 
"Turn: ietf:params:xml:ns: yang: ietf-yang-types" 
}, 
{ 
"name": "ietf-datastores", 
"revision": "2018-02-14", 
"namespace": 
"urn:ietf:params:xml:ns:yang:ietf—datastores" 
} 
] 
} 
l, 
"schema": [ 
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"name": "host-schema", 
K"module-set": [ "host-modules" ] 


) 
l; 


"datastore": [ 
{ 
"name": "ietf-datastores:running", 
K"schema": "host-schema" 
}, 
{ 
"name": "ietf-datastores:operational", 
"schema": "host-schema" 
} 
] 
}, 
"ietf-yang-schema-mount:schema-mounts": { 


"mount-point": [ 


{ 


"module": "ietf-network-instance", 
"label": "vrf-root", 
"shared-schema": { 


"parent-reference": [ 


"/*[namespace-uri() = ’urn:ietf: 


] 
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